HPAVC

home *** CD-ROM | disk | FTP | other *** search

/ HPAVC / HPAVC CD-ROM.iso / pc / UGPRG.ZIP / VGA-MISC / MODEX.DOC next >

Wrap

Text File | 1994-05-10 | 28.8 KB | 721 lines

┌────────────────────────┐ │ INTRODUCTION TO MODE X │ └────────────────────────┘ By Robert Schmidt <robert@stud.unit.no> ┌──────────────┬───────────────────────────────────────────────────────────── │ XINTRO18.TXT │ └──────────────┘ Title: INTRODUCTION TO MODE X Version: 1.8 Author: Robert Schmidt <robert@stud.unit.no> Copyright: (C) 1993 of Ztiff Zox Softwear - refer to Status below. Last revision: 25-Nov-93 (Modified for the PCGPE 17-Apr-94) Figures: 1. M13ORG - memory organization in mode 13h 2. MXORG - memory organization in unchained modes (Both files are appended to the end of this document) The figures are available as 7-bit ASCII text (ASC) files. Status: This article, its associated figures and source listings named above, are all donated to the public domain. Do with it whatever you like, but give credit where credit is due. The standard disclaimer applies. Index: 0. ABSTRACT 1. INTRODUCTION TO THE VGA AND ITS 256-COLOR MODE 2. GETTING MORE PAGES AND PUTTING YOUR FIRST PIXEL 3. THE ROAD FROM HERE 4. BOOKS ON THE SUBJECT 5. BYE - FOR NOW 0. ABSTRACT This text gives a fairly basic, yet technical, explanation to what, why and how Mode X is. It first tries to explain the layout of the VGA memory and the shortcomings of the standard 320x200 256-color mode, then gives instructions on how one can progress from mode 13h to a multipage, planar 320x200 256-color mode, and from there to the quasi-standard 320x240 mode, known as Mode X. A little experience in programming the standard VGA mode 13h (320x200 in 256 colors) is assumed. Likewise a good understanding of hexadecimal notation and the concepts of segments and I/O ports is assumed. Keep a VGA reference handy, which at least should have definitions of the VGA registers at bit level. Throughout the article, a simple graphics library for unchained (planar) 256-color modes is developed. The library supports the 320x200 and 320x240 modes, active and visible pages, and writing and reading individual pixels. 1. INTRODUCTION TO THE VGA AND ITS 256-COLOR MODE Since its first appearance on the motherboards of the IBM PS/2 50, 60 and 80 models in 1987, the Video Graphics Array has been the de facto standard piece of graphics hardware for IBM and compatible personal computers. The abbreviation, VGA, was to most people synonymous with acceptable resolution (640x480 pixels), and a stunning rainbow of colors (256 from a palette of 262,144), at least compared to the rather gory CGA and EGA cards. Sadly, to use 256 colors, the VGA BIOS limited the users to 320x200 pixels, i.e. the well-known mode 13h. This mode has one good and one bad asset. The good one is that each one of the 64,000 pixels is easily addressable in the 64 Kb video memory segment at 0A000h. Simply calculate the offset using this formula: offset = (y * 320) + x; Set the byte at this address (0A000h:offset) to the color you want, and the pixel is there. Reading a pixel is just as simple: just read the corresponding byte. This was heaven, compared to the havoc of planes and masking registers needed in 16-color modes. Suddenly, the distance from a graphics algorithm on paper to an implemented graphics routine in assembly was cut down to a fraction. The results were impressively fast, too! The bad asset is that mode 13h is also limited to only one page, i.e. the VGA can hold only one screenful at any one time (plus 1536 pixels, or about four lines). Most 16-color modes let the VGA hold more than one page, and this enables you to show one of the pages to the user, while drawing on another page in the meantime. Page flipping is an important concept in making flicker free animations. Nice looking and smooth scrolling is also almost impossible in mode 13h using plain VGA hardware. Now, the alert reader might say: "Hold on a minute! If mode 13h enables only one page, this means that there is memory for only one page. But I know for a fact that all VGAs have at least 256 Kb RAM, and one 320x200 256-color page should consume only 320*200=64000 bytes, which is less than 64 Kb. A standard VGA should room a little more than four 320x200 pages!" Quite correct, and to see how the BIOS puts this limitation on mode 13h, I'll elaborate a little on the memory organization of the VGA. The memory is separated into four bit planes. The reason for this stems from the EGA, where graphics modes were 16-color. Using bit planes, the designers chose to let each pixel on screen be addressable by a single bit in a single byte in the video segment. Assuming the palette has not been modified from the default, each plane represent one of the EGA primary colors: red, green, blue and intensity. When modifying the bit representing a pixel, the Write Plane Enable register is set to the wanted color. Reading is more complex and slower, since you can only read from a single plane at a time, by setting the Read Plane Select register. Now, since each address in the video segment can access 8 pixels, and there are 64 Kb addresses, 8 * 65,536 = 524,288 16-color pixels can be accessed. In a 320x200 16-color mode, this makes for about 8 (524,288/(320*200)) pages, in 640x480 you get nearly 2 (524,288/(640*480)) pages. In a 256-color mode, the picture changes subtly. The designers decided to fix the number of bit planes to 4, so extending the logic above to 8 planes and 256 colors does not work. Instead, one of their goals was to make the 256-color mode as easily accessible as possible. Comparing the 8 pixels/address in 16-color modes to the 1-to-1 correspondence of pixels and addresses of mode 13h, one can say that they have succeeded, but at a certain cost. For reasons I am not aware of, the designers came up with the following effective, but memory-wasting scheme: The address space of mode 13h is divided evenly across the four bit planes. When an 8-bit color value is written to a 16-bit address in the VGA segment, a bit plane is automatically selected by the 2 least significant bits of the address. Then all 8 bits of the data is written to the byte at the 16-bit address in the selected bitplane (have a look at figure 1). Reading works exactly the same way. Since the bit planes are so closely tied to the address, only every fourth byte in the video memory is accessible, and 192 Kb of a 256 Kb VGA go to waste. Eliminating the need to bother about planes sure is convenient and beneficial, but to most people the loss of 3/4 of the total VGA memory sounds just hilarious. To accomodate this new method of accessing video memory, the VGA designers introduced a new configuration bit called Chain-4, which resides as bit number 3 in index 4 of the Sequencer. In 16-color modes, the default state for this bit is off (zero), and the VGA operates as described earlier. In the VGA's standard 256-color mode, mode 13h, this bit is turned on (set to one), and this turns the tieing of bit planes and memory address on. In this state, the bit planes are said to be chained together, thus mode 13h is often called a _chained mode_. Note that Chain-4 in itself is not enough to set a 256-color mode - there are other registers which deals with the other subtle changes in nature from 16 to 256 colors. But, as we now will base our work with mode X on mode 13h, which already is 256-color, we won't bother about these for now. 2. GETTING MORE PAGES AND PUTTING YOUR FIRST PIXEL The observant reader might at this time suggest that clearing the Chain-4 bit after setting mode 13h will give us access to all 256 Kb of video memory, as the two least significant bits of the byte address won't be `wasted' on selecting a bit plane. This is correct. You might also start feeling a little uneasy, because something tells you that you'll instantly loose the simple addressing scheme of mode 13h. Sadly, that is also correct. At the moment Chain-4 is cleared, each byte offset addresses *four* sequential pixels, corresponding to the four planes addressed in 16-color modes. Every fourth pixel belong in the same plane. Before writing to a byte offset in the video segment, you should make sure that the 4-bit mask in the Write Plane Enable register is set correctly, according to which of the four addressable pixels you want to modify. In essence, it works like a 16-color mode with a twist. See figure 2. So, is this mode X? Not quite. We need to elaborate to the VGA how to fetch data for refreshing the monitor image. Explaining the logic behind this is beyond the scope of this getting-you-started text, and it wouldn't be very interesting anyway. Also, mode 13h has only 200 lines, while I promised 240 lines. I'll fix that later below. Here is the minimum snippet of code to initiate the 4 page variant of mode 13h (320x200), written in plain C, using some DOS specific features (see header for a note about the sources included): ----8<-------cut begin------ /* width and height should specify the mode dimensions. widthBytes specify the width of a line in addressable bytes. */ int width, height, widthBytes; /* actStart specifies the start of the page being accessed by drawing operations. visStart specifies the contents of the Screen Start register, i.e. the start of the visible page */ unsigned actStart, visStart; /* * set320x200x256_X() * sets mode 13h, then turns it into an unchained (planar), 4-page * 320x200x256 mode. */ set320x200x256_X() { union REGS r; /* Set VGA BIOS mode 13h: */ r.x.ax = 0x0013; int86(0x10, &r, &r); /* Turn off the Chain-4 bit (bit 3 at index 4, port 0x3c4): */ outport(SEQU_ADDR, 0x0604); /* Turn off word mode, by setting the Mode Control register of the CRT Controller (index 0x17, port 0x3d4): */ outport(CRTC_ADDR, 0xE317); /* Turn off doubleword mode, by setting the Underline Location register (index 0x14, port 0x3d4): */ outport(CRTC_ADDR, 0x0014); /* Clear entire video memory, by selecting all four planes, then writing 0 to the entire segment. */ outport(SEQU_ADDR, 0x0F02); memset(vga+1, 0, 0xffff); /* stupid size_t exactly 1 too small */ vga[0] = 0; /* Update the global variables to reflect the dimensions of this mode. This is needed by most future drawing operations. */ width = 320; height = 200; /* Each byte addresses four pixels, so the width of a scan line in *bytes* is one fourth of the number of pixels on a line. */ widthBytes = width / 4; /* By default we want screen refreshing and drawing operations to be based at offset 0 in the video segment. */ actStart = visStart = 0; } ----8<-------cut end------ As you can see, I've already provided some of the mechanics needed to support multiple pages, by providing the actStart and visStart variables. Selecting pages can be done in one of two contexts: 1) selecting the visible page, i.e. which page is visible on screen, and 2) selecting the active page, i.e. which page is accessed by drawing operations Selecting the active page is just a matter of offsetting our graphics operations by the address of the start of the page, as demonstrated in the put pixel routine below. Selecting the visual page must be passed in to the VGA, by setting the Screen Start register. Sadly enough, the resolution of this register is limited to one addressable byte, which means four pixels in unchained 256-color modes. Some further trickery is needed for 1-pixel smooth, horizontal scrolling, but I'll make that a subject for later. The setXXXStart() functions provided here accept byte offsets as parameters, so they'll work in any mode. If widthBytes and height are set correctly, so will the setXXXPage() functions. ----8<-------cut begin------ /* * setActiveStart() tells our graphics operations which address in video * memory should be considered the top left corner. */ setActiveStart(unsigned offset) { actStart = offset; } /* * setVisibleStart() tells the VGA from which byte to fetch the first * pixel when starting refresh at the top of the screen. This version * won't look very well in time critical situations (games for * instance) as the register outputs are not synchronized with the * screen refresh. This refresh might start when the high byte is * set, but before the low byte is set, which produces a bad flicker. * I won't bother with this now. */ setVisibleStart(unsigned offset) { visStart = offset; outport(CRTC_ADDR, 0x0C); /* set high byte */ outport(CRTC_ADDR+1, visStart >> 8); outport(CRTC_ADDR, 0x0D); /* set low byte */ outport(CRTC_ADDR+1, visStart & 0xff); } /* * setXXXPage() sets the specified page by multiplying the page number * with the size of one page at the current resolution, then handing the * resulting offset value over to the corresponding setXXXStart() * function. The first page number is 0. */ setActivePage(int page) { setActiveStart(page * widthBytes * height); } setVisiblePage(int page) { setVisibleStart(page * widthBytes * height); } ----8<-------cut end------ Due to the use of bit planes, the graphics routines tend to get more complex than in mode 13h, and your first versions will generally tend to be a little slower than mode 13h algorithms. Here's a put pixel routine for any unchained 256-color mode (it assumes that the 'width' variable from the above code is set correctly). Optimizing is left as an exercise to you, the reader. This will be the only drawing operation I'll cover in this article, but all general primitives like lines and circles can be based on this routine. (You'll probably not want to do that though, due to the inefficiency.) ----8<-------cut begin------ putPixel_X(int x, int y, char color) { /* Each address accesses four neighboring pixels, so set Write Plane Enable according to which pixel we want to modify. The plane is determined by the two least significant bits of the x-coordinate: */ outportb(0x3c4, 0x02); outportb(0x3c5, 0x01 << (x & 3)); /* The offset of the pixel into the video segment is offset = (width * y + x) / 4, and write the given color to the plane we selected above. Heed the active page start selection. */ vga[(unsigned)(widthBytes * y) + (x / 4) + actStart] = color; } char getPixel_X(int x, int y) { /* Select the plane from which we must read the pixel color: */ outport(GRAC_ADDR, 0x04); outport(GRAC_ADDR+1, x & 3); return vga[(unsigned)(widthBytes * y) + (x / 4) + actStart]; } ----8<-------cut end------ However, by now you should be aware of that the Write Plane Enable register isn't limited to selecting just one bit plane, like the Read Plane Select register is. You can enable any combination of all four to be written. This ability to access 4 pixels with one instruction helps quadrupling the speed in certain respects, especially when drawing horizontal lines and filling polygons of a constant color. Also, most block algorithms can be optimized in various ways so that they need only a constant number of OUTs (typically four) to the Write Plane Enable register. OUT is a relatively slow instruction. The gained ability to access the full 256 Kb of memory on a standard VGA enables you to do paging and all the goodies following from that: smooth scrolling over large maps, page flipping for flicker free animation... and I'll leave something for your own imagination. In short, the stuff gained from unchaining mode 13h more than upweighs the additional complexity of using a planar mode. Now, the resolution of the mode is of little interest in this context. Nearly any 256-color resolution from (about) 80x8 to 400x300 is available for most VGAs. I'll dwell particularly by 320x240, as this is the mode that Michael Abrash introduced as 'Mode X' in his DDJ articles. It is also the resolution that most people refer to when using that phrase. The good thing about the 320x240 mode is that the aspect ratio is 1:1, which means that each pixel is 'perfectly' square, i.e. not rectangular like in 320x200. An ellipse drawn with the same number of pixels along both main axes will look like a perfect circle in 320x240, but like a subtly tall ellipse in 320x200. Here's a function which sets the 320x240 mode. You'll notice that it depends on the first piece of code above: ----8<-------cut begin------ set320x240x256_X() { /* Set the unchained version of mode 13h: */ set320x200x256_X(); /* Modify the vertical sync polarity bits in the Misc. Output Register to achieve square aspect ratio: */ outportb(0x3C2, 0xE3); /* Modify the vertical timing registers to reflect the increased vertical resolution, and to center the image as good as possible: */ outport(0x3D4, 0x2C11); /* turn off write protect */ outport(0x3D4, 0x0D06); /* vertical total */ outport(0x3D4, 0x3E07); /* overflow register */ outport(0x3D4, 0xEA10); /* vertical retrace start */ outport(0x3D4, 0xAC11); /* vertical retrace end AND wr.prot */ outport(0x3D4, 0xDF12); /* vertical display enable end */ outport(0x3D4, 0xE715); /* start vertical blanking */ outport(0x3D4, 0x0616); /* end vertical blanking */ /* Update mode info, so future operations are aware of the resolution: */ height = 240; } ----8<-------cut end------ As you've figured out, this mode will be completely compatible with the utility functions presented earlier, thanks to the global variable 'height'. Boy, am I foreseeing or what! Other resolutions are achieved through giving other values to the sync timing registers of the VGA, but this is quite a large and complex subject, so I'll postpone this to later, if ever. Anyway, I hope I've helped getting you started using mode X. As far as I know, the two modes I've used above should work on *any* VGA and Super VGA available, so this is pretty stable stuff. Let me know of any trouble, and - good luck! 3. THE ROAD FROM HERE I'm providing information on various libraries and archives which relate to what this article deals with. If you want me to add anything to this list (for future articles), let me know, although I can't promise anything. I am assuming you have ftp access. wuarchive.wustl.edu:/pub/MSDOS_UPLOADS/programming/xlib06.zip This is the current de facto C/assembler library for programming unchained modes (do not confuse with a X Windows library). All sources are included, and the library is totally free. It has functions for pixels, lines, circles, bezier curves, mouse handling, sprites (bitmaps), compiled bitmaps, and supports a number of resolutions. The version number ('06') is current as of November 1993. graphprg.zip Michael Abrash' articles in Doctor Dobbs Journal is always mentioned with awe. In this 350 Kb archive, most of his interesting stuff has been gathered. Read about Mode X development and techniques from month to month. Included is also all the individual source code snippets from each article, and also the full XSHARP library providing linedrawing, polygons, bitmaps, solid 3D projection and speedy rendering, and even an implementation of 2D texture mapping (can be used for quasi-3D texture mapping), plus an article on assembly optimization on the i86 processor family. Definitely recommended. oak.oakland.edu:/pub/msdos/vga/vgadoc2.zip This is a bare bones VGA register reference. It also contains register references for the CGA, EGA and Hercules cards, in addition to dozens of SuperVGAs. Check out the BOOKS section for some decent VGA references though - you don't want to start tweaking without a real one. wuarchive.wustl.edu:/pub/MSDOS_UPLOADS/programming/tweak15b.zip TWEAK might be of interest to the more adventurous reader. TWEAK lets you play around with the registers of the VGA in an interactive manner. Various testing screens for viewing your newmade modes are applied at the press of a key. Version 1.5 adds a test screen which autodetects your graphics mode and displays various information about resolutions etc. Keep a VGA reference handy. Don't try it if this is the first time you've heard of 'registers' or 'mode X' or 'tweaking'. I was planning a version based on the Turbo Vision interface, but time has been short. Maybe later! 4. BOOKS ON THE SUBJECT Extremely little has been published in written form about using 'Mode X'-style modes. Below are some books which cover VGA programming at varying degrees of technical level, but the only one to mention unchained modes and Mode X, is Michael Abrash'. I'd get one of the VGA references first, though. o George Sutty & Steve Blair : "Advanced Pogrammer's Guide to the EGA/VGA" from Brady. A bit old perhaps, but covers all *standard* EGA/VGA registers, and discusses most BIOS functions and other operations. Contains disk with C/Pascal/assembler source code. There's a sequel out for SuperVGAs, which I haven't seen. o Michael Abrash : "Power Graphics Programming" from QUE/Programmer's Journal. Collections of (old) articles from Programmer's Journal on EGA/VGA, read modes and write modes, animation, tweaking (320x400 and 360x480). His newer ravings in DDJ covers fast 256-color bitmaps, compiled bitmaps, polygons, 3D graphics, texture mapping among other stuff. o Richard F. Ferraro : "Programmer's Guide to the EGA and VGA video cards including Super VGA". I don't have this one, but heard it's nice. Detailed coverage of all EGA/VGA registers. The Super VGA reference makes it attractive. o Richard Wilton : "Programmer's Guide to PC & PS/2 Video Systems" Less technical, more application/algorithm oriented. Nice enough, even though it is a bit outdated, in that he discusses CGA and Hercules cards just as much as EGA/VGA. 5. BYE - FOR NOW I am considering writing a text describing in more detail the process of using TWEAK to achieve the VGA resolution you want or need. However, I thought I'd let this document go first, and see if I get any reactions. If I don't, I'll stop. Feel free to forward any suggestions, criticisms, bombs and beers. I can be reached via: o e-mail: robert@stud.unit.no o land mail: Robert Schmidt Stud.post 170 NTH N-7034 Trondheim NORWAY Nothing would encourage or please me more than a postcard from where you live! ┌───────────┬──────────────────────────────────────────────────────────────── │ M1ORG.ASC │ └───────────┘ Figure 1: Memory organization in mode 13h (ASCII version) by Robert Schmidt (C) 1993 Ztiff Zox Softwear a. Imagine that the top of the screen looks like this (pixel values are represented by color digits 0-9 for simplicity - actual colors may range from 0 to 255) - a screen width of 320 pixels is assumed: address: 0 10 310 319 ---------------------------------------- |0123456789012345 ..... 0123456789| | | | | | b. In VGA memory, the screen is represented as follows (question marks represent unused bytes): Plane 0: address: 0 10 310 319 ---------------------------------------- |0???4???8???2??? ..... ??2???6???| | | | | Plane 1: address: 0 10 310 319 ---------------------------------------- |?1???5???9???3?? ..... ???3???7??| | | | | Plane 2: address: 0 10 310 319 ---------------------------------------- |??2???6???0???4? ..... 0???4???8?| | | | | Plane 3: address: 0 10 310 319 ---------------------------------------- |???3???7???1???5 ..... ?1???5???9| | | | | I.e. a plane is selected automatically by the two least significant bits of the address of the byte being read from or written two. This renders 3/4 of the video memory unavailable and useless, but all visible pixels are easily accessed, as each address in the video segment provides access to one and ONLY ONE pixel. ┌───────────┬──────────────────────────────────────────────────────────────── │ MXORG.ASC │ └───────────┘ Figure 2: Memory organization in unchained 256-color modes (like Mode X) (ASCII version) by Robert Schmidt (C) 1993 Ztiff Zox Softwear Imagine that the screen looks the same as in figure 1a. A screen width of 320 pixels is still assumed. In VGA memory, the screen will be represented as follows: Plane 0: address: 0 10 70 79 (NOT 319!) ---------------------------------------- |0482604826048260 ..... 0482604826| | | | | Plane 1: address: 0 10 70 79 ---------------------------------------- |1593715937159371 ..... 1593715937| | | | | Plane 2: address: 0 10 70 79 ---------------------------------------- |2604826048260482 ..... 2604826048| | | | | Plane 3: address: 0 10 70 79 ---------------------------------------- |3715937159371593 ..... 3715937159| | | | | Note that if pixel i is in plane p, pixel i+1 is in plane (p+1)%4. When the planes are unchained, we need to set the Write Plane Enable register to select which planes should receive the data when writing, or the Read Plane Select register when reading. As is evident, one address in the video segment provides access to no less than FOUR different pixels. ┌───────┬─────────────────────────────────────────────────────────────────── │ Zox3D │ └───────┘ Available via ftp : ftp.wustl.edu:/pub/MSDOS_UPLOADS/games/programming/zox3d15.zip wasp.eng.ufl.edu:/pub/msdos/demos/<somewhere>/zox3d15.zip zox3d15.zip contains a demo of my 3D graphics engine. It resembles Wolf3D, but has a number of additional features: - texture mapped floor and ceiling (sky, in this demo) - real, recursive MIRRORS! - partly TRANSPARENT walls - input from keyboard, joystick and mouse (at the same time, too, if you wish) - controllable camera height - NOT fixed like Wolf3D - quick resizable window - online help and fps rating - advanced collision detection and handling - supports a variety of tweaked X modes, from 256x256 to 400x300. The sky and mirrors have to be seen to be beleived! Zox3D does NOT implement objects, like the guards in Wolf3D, but that should be a breeze to add. The complete sources are available. Read ZOX3D.DOC in the demo archive for information. ──────────────────────────────────────────────── Robert Schmidt - robert@stud.unit.no - Buuud@IRC